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Description 

This invention relates to a method for maintain- 
ing data availability in a restartable data base sys- 
tem, and more particularly, where the system is 
externally accessible by at least one terminal. 

It has long been appreciated that continuity of 
service can be maintained If a backup processor or 
system can be substituted for a degrading active 
processor or system. Examples may be found in 
air defense systems (SAGE), command and control 
(SAC), astronautics (APOLLO), and airiine reserva- 
tion systems (SABRE). Such systems employed 
multiple processors operating in tandem on the 
same data such that, If an active system failed, its 
backup could replace it. Alternatively, by having 
multiple processors operating in tandem, it might 
be possible for an operator to pick and choose 
either which processor could be treated as the 
active controlling processor, or whether the results 
arrived at were credible. Such systems rarely con- 
cern themselves with maintaining the integrity of 
transactions caught in the middle when a backup 
processor replaces an active degrading processor. 
For example, in tiie airline reservation systems, it 
was the responsibility of the ticket agent to confirm 
the status of any transactions in process and ini- 
tiate any recovery procedures, and not that of the 
system itself. 

Other pertinent prior art includes Doblmaier et 
al, USP 3,623,008. "Progranr>-controlled Data Pro- 
cessing System", issued November 23, 1971; 
Downing et al, USP 3.651.480. "Program Con- 
trolled Data Processing System", issued March 21 , 
1972; and Griscom et al. USP 4,455,601. "Cross 
Checking Among Service Processors in a Mul- 
tiprocessor System", issued June 19. 1984. 

Doblmaier and Downing describe fault toler- 
ance in a telephone switching system having active 
and backup processors for controlling telephone 
connection traffic. In their system, denominated 
electronic switching system (ESS), each proces- 
sor's components such as memory or control ar- 
rangements are switchably interconnectable there- 
between. This means that a faulty memory in the 
active processor may be replaced immediately by 
its counterpart from a backup processor. This re- 
quires that a near-identical information state be 
maintained among the components of both proces- 
sors in order to minimize k>ss of either calls in 
progress or calls being processed affected by this 
switchover. 

The present invention is disclosed in the at- 
tached claims. 

It is an object of this invention to devise a 
method for maintaining data availability in restar- 
table data base systems. It is a related object to 
devise a method for overlapping new transactbns 



with restart recovery operations in such data base 
systems while maximizing transaction integrity and 
conastency. 

The foregoing objects are attained in a method 

5 for maintaining switchover between a backup and 
degrading active processor, which switchover is 
transparent to a terminal accessing the active pro- 
cessor with atomic transactions. The backup pro- 
cessor prepares for an outage by the active pro- 

10 cesser by synchronizing, tracking, and monitoring 
the active processor's log entries. When the active 
processor fails, the backup processor performs the 
necessary recovery processing and takes over 
user-transaction processing as the new active pro- 

75 cesser. Synchronization Is manifest in the form of 
taking a "snapshot" of the active processor's cur- 
rent status as recorded on the active processor's 
log. Tracking is accomplished by scanning the 
active processor's log updates. Thus, by following 

20 the system log, the backup processor neither du- 
plicates the same processing as tiiat done of the 
active processor, nor is it involved with the pro- 
cessing on the active system. 

Advantageously, the invention involves continu- 

25 ous updating of the t>ackup processor through a 
path including the terminal, active processor, and 
togging facility. In this regard, the active processor 
updates the log while the backup processor polls 
the log for updates. This stands in contrast to the 

30 Doblmaier and Downing references which describe 
systems relying upon replicates of the same data 
base. Indeed, in this invention, a "snapshot" for 
synchronization with updates is being used for 
tracking. 

35 

Brief Description of the Drawing 

Rgure 1 illustrates the active and alternate data 
base system configuration according to the inven- 
40 tion. 

Rgure 2 depicts the intersubsystem commu- 
nication. 

Rgure 3 sets out the phased flow of control 
between the active and backup processors. 
45 Rgure 4 emphasizes the relationship between 
the active and backup processors with reference to 
an attached commonly accessing terminal. 

Rgure 5 shows a sample activealternate con- 
figuration. 

50 Rgures 6-9 set out assembly-level language 
code traces for respectively establishing an op- 
tional link, reading the active processor's log, pro- 
cessing the active processor's log records, and 
processing the active processor's snapshot check- 
55 pointing activity. 

Rgure 10 sets out a dependent region restart 
table structure. 

Rgures 11-13 depict structures involved in lock 
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and buffer tracking of pool structures and buffer 
tracking table entries. 

Figure 14 shows a Fast Path "indoubt" buffer 
reduction. 

Rgure 15 depicts a timer tracking overview. s 
Figures 16-17 illustrate assembly language 
backup processor takeover from the inactive pro- 
cessor. 

Description of the Preferred Embodiment and In- io 
dustrial Applicability 

THE FOLLOWING IS A LIST OF ABBREVIATIONS 
OCCURING IN THE TEXT AND THEIR MEANING 



ACF 


Advanced Ck>mmunication Function 


IMS 


Infonmation Managment System 


ISC 


Intersystem Communication 


LU 


Logical Unit 


NCP 


Network Control Program 


RDS 


Restart Data Set 


VS 


Virtual Storage 


VTAM 


Virtual Telecommunications Access 




Metiiod 


XRF 


Extended Recovery Facility 



In the prior art of Information Management Sys- 
tem (IMS), outage recovery was handled through 
an emergency restart procedure. To support an 
emergency restart each IMS system always 
logged all events and infonmation needed for recov- 30 
ery. When the system failed, the operator would 
restart the job by entering a command that in- 
formed tiie IMS system that this was an emer- 
gency restart. IMS wouki then read the log records 
created by the failed IMS system in order to per- 35 
form whatever recovery work was required, and 
would then continue processing where the failed 
system had left off. Among the factors which were 
necessarily involved in the recovery included bring- 
ing up another IMS system in emergency restart 40 
mode, performing recovery processing (backouts 
and forward recoveries), manually starting depen- 
dent regions and restarting all terminal sessions, 
and upon demand, authorizing, allocating, and re- 
opening data bases. 45 

In contrast to past requisites, the method of 
this invention brings up a backup processor which 
can, by processing the active processor's log 
records, monitor the state of the active processor 
and take over for the "active processor" in the 50 
event of a planned shutdown or unplanned failure. 
The backup processor is not merely duplicating the 
same processing as tfte "active", nor is it involved 
in any way with the processing by the active pro- 
cessor. Rather, the backup processor extracts sta- 55 
tus and recovery Information from the active pro- 
cessor's log and does whatever preprocessing it 
can so that the takeover can be performed with 
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minimal interruption to tiie end user. 

Referring now to Rgure 1. there is shown a 
configuration of active and backup or "alternate" 
configurations. The data t>ase is shared between 
the active and backup processors. The active pro- 
cessor's IMS log is made available to the backup. 
The t)ackup processor prepares for an outage by 
"synchronizing" with the active processor, 
"tracking it", and "monitoring it" for signs of failure. 
When the active processor degrades, the backup 
performs the necessary recovery processing and 
takes over user-transaction processing responsibil- 
ity as the "new" active processor. The transfer of 
responsibility includes the making available to the 
tiackup processor of all data bases that were avail- 
able to the active processor, as well as the transfer 
of active terminal sessions to the backup proces- 
sor. Thus, the two IMSA/S subsystems shown In 
Rgure 1 work together to appear as a single active 
IMSA^S system to the end user. 

When starting on the same or different proces- 
sor, the backup system requests the active proces- 
sor to take a checkpoint (snapshot) of its cunrent 
status. The backup processor obtains this check- 
point data from the active processor's log and uses 
it to achieve "synchronization" with the active pro- 
cessor. The backup then tracks and reflects any 
active processor status changes by concurrentiy 
accessing the log data being produced by the 
active processor. 

The backup processor monitors the activities of 
the active processor, looking for signs of failure. 
These surveillance functions can include several 
methods for detecting conditions requiring the initi- 
ation of a "takeover". TTiese methods include utili- 
zation of the active processor's log and a Restart 
Data Set (RDS). 

Referring now to Rgure 2, there is shown the 
communication between the active and backup pro- 
cessors. It should be noted that the backup proces- 
sor scans tiie IMS log of the active processor and 
the Restart Data Set and shares a communication 
link designated as VTAM LU6. 

TTie following section is organized into the 
problems to be solved and how this invention ad- 
dresses them. The explanation is more easily un- 
derstood within the context of specific processing 
phases as depicted in Rgure 3. References to the 
phases in this figure will be made in the description 
that follows. A later section will use these phases to 
follow an example of an IMS/XRF (Extended Re- 
covery Facility) "alternate" sut>system taking over 
for a failing "active" subsystem. 

Establishing End User Sessions 

When an IMS subsystem is started, terminal 
sessions are started to allow the user to enter 
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transactions into IMS. Except for the functions de- 
scribed in the following paragraphs, the nnethod of 
connecting a VTAM-controlled terminal to IMS has 
not changed. The following VTAM nnanuals de- 
scribe the session establishment method before 5 
the XRF changes: 

1. ACFA/TAM V2 General Information, IBM pub- 
lication GC27-0608. 

2. ACFA/TAM V2 Planning and Installation,! BM 
publication SC27-0610. w 

3. ACFAO'AM V2 Operation, IBM publication 
SC27-0612. 

In order to allow IMS to appear to the end 
tenminal user as a "single system image", VTAM 
implemented User Application Name Variable sup- is 
port. Using this name, an end tenminal user can 
connect to the active IMS subsystem with the ca- 
pability of processing transactions witiiout knowing 
the actual VTAM application name of the IMS sub- 
system. This is because VTAM will translate the 20 
User Application Name Variable to the actual 
VTAM Application Name set by IMS when it be- 
comes an active subsystem capable of processing 
transactions. 

Also, VTAM and NOP were modified to indicate 25 
on the CINIT, presented to the active IMS during 
session establishment, whether the connection can 
support an XRF-capable session. If so, IMS will 
BIND an XRF-capable session on tiie "active". Ttiis 
will result in additional storage being allocated by 30 
NCR for the session to maintain extra session 
status information. The log records written at)out 
these sessions will indicate whether or not an XRF- 
capable session was established. 

Should an alternate subsystem be present, a 35 
backup session will be estat>lished for each XRF- 
capable session as part of the 
synchronization/bracking process. This will allow a 
very fast, session-preserving switch of the terminal 
at takeover. And the return of NCP-maintained ses- 40 
sion status Information to IMS allows IMS to per- 
form "session recovery" as needed to provide end- 
user transparency. Session recovery is explained in 
later sections. 

45 

Monitoring the State of the Active Subsystem 

The alternate subsystem must synchronize it- 
self with the active subsystem at a specific time so 
that it can trac* the "active's" processing from that 50 
point on. The active subsystem takes a "SNAPQ" 
Checkpoint for this purpose. It consists of a set of 
log records whrch contains the status of the system 
at the time the checkpoint was taken. The 
"SNAPQ" Checkpoint is taken by the "active" ei- 55 
ther by a direct request from the "alternate" via the 
optional ISC link or by operator command. The 
operator, in the latter case, receives a message 



from the "alternate" requesting that a /CHE SNAPQ 
command be entered in the active subsystem. 
When these checkpoint records are written to the 
"active's" system log, the "alternate" reads and 
processes them for its synchronization. 

Once the alternate subsystem has determined 
an initial or starting status of the active subsystem 
from the "SNAPQ" Checkpoint, the status of the 
"active" is maintained by the "alternate" from the 
update log records produced by the "active". In 
Figure 3, this activity Is depicted by the Synchro- 
nization Phase and the Tracking Phase. 

This monitoring or tracking activity by the al- 
tennate sut)system serves three purposes and will 
be described in terms of tiiese purposes. 

1. The "alternate" maintains sufficient information 
about the "active" to enable it to take over. 

The IMSA/S SNAPQ Checkpoint log records 
and related "change" records were expanded to 
include sufficient information to allow the altemate 
subsystem to: 

(a) Identify and maintain ^e current status of the 
"active's" network— which sessions are active. 
This information is used to transfer the commu- 
nications relationship between user and system 
from the active to the altemate subsystem when 
a takeover is performed. 

(b) Identify and maintain the current status of 
scheduled application programs. 

When an application program is scheduled 
from a terminal, the data base system must load 
a set of control blocks that support the schedul- 
ing function. It must also determine which data 
bases the application program can access and 
load the associated data base description and 
control blocks. When the application program 
terminates, these control blocks are released. It 
is therefore necessary for the active subsystem 
to inform ttie "altemate" of application program 
initiation and termination via the system log. 
This enables the "alternate" to have the neces- 
sary control blocks loaded for applications that 
were active at the time of a failure. 

(c) Identify and track which data bases are open, 
which are closed, and which are stopped. 

To preserve the single-system image to the 
end user, tiie alternate subsystem must track 
the exact state of all of the data bases. This Is 
accomplished by making the active subsystem 
log the following data base activities: 

- data base op^n/close activities, 

- data base data set allocation/deallocation 
activities, and 

- data base authorization and share level 
activities. 

This information allows the altemate sub- 
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system to see that data bases that were avail- 
able to end users at the time of the active 
subsystem's failure will be available to them 
after the takeover. 

(d) Identify and maintain the cunrent status of "in 
flight" data base changes to support possible 
data base recovery processing after a takeover. 

(e) Identify and track any data-sharing locks that 
are currently held by the active subsystem. This 
is done to allow the alternate subsystem, at 
takeover time, to reacquire locks held by the 
"active" at the time of the failure. With these 
locks the "altemate", upon taking over for the 
"active", can allow new transactions to begin in 
parallel with backout and forward recovery pro- 
cessing (for which the locks were reacquired). 

(f) Ensure that the "clock" on the alternate sut>- 
system is not earlier than the "clock" on the 
"active". This must be done to keep from de- 
stroying the integrity of the data bases after a 
takeover. 

IMS/XRF logic was added to compare the 
timestamp of the first record of the SNAPQ 
Checkpoint to the cunrent time in the altemate 
subsystem. If the "alternate's" time is earlier 
than the "active's" timestamp, an adjustment 
factor Is calculated and applied to all 
timestamps generated by the "altemate". It was 
also necessary to recalculate the adjustment 
factor for certain critical logs throughout the 
Tracking Phase. 

2. The "altemate" does as much preprocessing as 
possible in order to speed up the takeover process. 

The following preprocessing methods were im- 
plemented in IMS/XRF to reduce the elapsed time 
from the failure of the active subsystem to the 
enabling of end-user transactions on the altemate 
subsystem: 

(a) Initiate backup tenminal sessions 

The objective here is to transfer the commu- 
nications relationship between user and system 
from the active to the alternate subsystem as 
quickly as possible with little or no disruption to 
the end user. 

To minimize network switching time, modi- 
tications were made to ACF/NCP and to 
ACF/VTAM to support the establishment of bac- 
kup terminal sessions concurrent with active 
sessions and the ability to switch terminal activ- 
ity to the backup sessions (thus making them 
the active sessions), and to return session status 
information to the altemate subsystem. Given 
this support, IMS/XRF contains modifications to 
albw the altemate subsystem to: 

- request backup terminal sessions upon re- 
ceipt of log records from the "active" in- 



forming the "altemate" that an XRF-ca- 
pable terminal session has been estab- 
lished, 

- request; at takeover time, a network switch 
5 causing each backup session to take over 

as the active session, and 

- compare the session status information re- 
turned from the networi< switch to the log- 
derived information in order to recover the 

10 communication state with transparency to 

the end terminal user. This is called 
"session recovery". 
From the terminal user's viewpoint, there is 
only one session. But from tiie Network Control 
75 Program's viewpoint, there can be two sessions 
per terminal, only one of which is active. This 
relationship is pictured in Figure 4 as imple- 
mented in IMS/XRF. 

(b) Preload Application Program Scheduling 
20 blocks 

The toading of the control blocks that sup- 
port scheduling for each active application pro- 
gram during a takeover would delay completion 
of the takeover considerably. The solution here 
25 was to modify IMS to log sufficient information 
so that the "alternate" can preload most or all of 
these blocks during the Tracking Phase. 

(c) Preallocate/preopen data bases 

To reduce or eliminate the need for the 
30 time-consuming process of dynamically allocat- 
ing and opening data base data sets after the 
takeover process has begun, the alternate sub- 
system performs these functions during the 
Tracking Phase based upon data base status 
35 information logged by the "active". When data 
bases are closed and unallocated by the 
"active", the "alternate" is informed via the sys- 
tem log so that it can follow suit. 

(d) Preauthorize data bases 

40 Data base authorization refers to tiie pro- 

cess of determining, for a potential user, wheth- 
er or not a data base is accessible. For exam- 
ple, a data base that has been stopped due to a 
backout failure is not accessible until recovery 

45 processing has been completed. By making the 
active subsystem log all authorization-related ac- 
tivity, the alternate subsystem can use these 
logs to drive its authorization processing during 
the Tracking Phase. IMS/XRF implemented this 

50 concept by allowing the altemate subsystem to 
"inherit" current data base authorizations from 
the failed "active". In this case, all the 
"altemate" has to do is track the "active's" 
authorization activity so that it knows what it has 

55 inherited. 

3. The "altemate" executes a surveillance function 
in order to detect a potential failure in the active 
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subsystem. 

The atternate subsystem uses several methods 
to automatically detect a potential failure o1 the 
active subsystem. All surveillance mechanisms in 5 
IMS/XRF are under direct user control. The user 
selects which mechanisms to activate and specifies 
what the time-out values of each shall be. The 
surveillance mechanisms are: 

(a) DASD surveillance io 
For this mechanism, a data set on shared 

DASD, which is regularly updated by the 
"active", is required. IMS/XRF uses its Restart 
Data Set. The "active" periodically updates a 
timestamp in the data set. The attemate sub- 75 
system periodically checks the timestamp to 
determine if the user-specified time interval has 
elapsed without the timestamp being updated, tf 
so, takeover decision logic is invoked. 

(b) LOG surveillance 20 
The "alternate" periodically checks the sys- 
tem log to detennine if the user-specified time 
interval has elapsed since the last log record 

was received from the "active". If so. takeover 
decision logic is invoked. 25 

(c) LINK surveillance 

IMS/XRF allows an optional LU6 (ISC) link 
between the two subsystems to be used for 
surveillance purposes. When the link is used, 
the active subsystem sends messages on a 30 
regular basis via this link. The "alternate" pe- 
riodically checks the link to see that these mes- 
sages are still being received. If the user-speci- 
fied time Interval between messages is sur- 
passed, takeover decision bgic is invoked. 35 

(d) LOG status surveillance 

The active subsystem generates log records 
to inform the "attemate" of at)normat conditions. 
This Information can then be used by the sur- 
veillance function to determine If takeover de- 40 
cision logic shoukl be invoked. Some examples 
of abnormal conditions might be: 

- IMS Resource Lock Manager failure, 

- VTAM failure, or 

- an IMS abend. 45 
In addition to selecting surveillance mecha- 
nisms, the user can also select which combinations 

of surveillance mechanism failures are to result in a 
takeover. Furthermore, the user can Indicate wheth- 
er the takeover Is to be automatk:aily initiated or so 
whether the Master Terminal Operator is to be 
informed of the failure. In the fatter case, the Mas- 
ter Terminal Operator has the option of initiating 
the takeover. This takeover decision logic is in- 
voked whenever any of the selected surveillance 55 
mechanisms detects a problem. 

Workload Transfer to the Alternate Subsystem 



Tills section includes those activities necessary 
for the alternate subsystem to take over end-user 
processing responsibilities from the failing active 
subsystem. 

The following functions are perfonnned before 
new end-user transaction processing is enabled: 

1. Prohibit further logging by the active sub- 
system. 

2. Rnish processing the active's system log. 

3. Notify operators. Lock Manager (IRLM), and 
Data Base Recovery Control (DBRC) of the 
takeover. 

4. Protect IMS resources by reacquiring locks 
held by the failing active subsystem. 

5. Invoke the I/O Toleration function. 

This function allows the takeover to com- 
plete even though the backup subsystem cannot 
guarantee that I/O Prevention has completed on 
the active subsystem. I/O Toleration intercepts 
attempts to write to those portions of the data 
base that could be overwritten by the degrading 
"active" and saves the results in buffers. When 
I/O Prevention completes, the I/O Toleration 
function then does the physical writes to the 
data bases from the buffers that it has main- 
tained. 

As each terminal session gets switched to the 
alternate subsystem, the end user can begin enter- 
ing new transactions. At first, the transactions are 
limited to those portions of the data base not 
requiring backout or forward recovery processing. 
But as soon as the backout and forward recovery 
processing finishes with a portion of the data base, 
that portion is immediately made available to the 
end user. Once all backout arKj forward recovery 
processing has completed, the altemate subsystem 
will be operating just like the active subsystem 
before it failed. 

The functions listed below are performed in 
parallel with the processing of new transactions: 
1. At takeover, IMS sets the VTAM User Ap- 
plication Name Variable to the "alternate's" 
VTAM application ID. This will direct all new 
end-user logon requests to the now active al- 
ternate subsystem. It then initiates communica- 
tions network switching which makes the backup 
VTAM sessions the active sessions without los- 
ing session control. This is done by changing 
the mode of the preestablished backup session 
to "active". 

As mentioned earlier, ACF/NCP maintains 
session status information and returns this in- 
formation to the IMS subsystem that is taking 
over. By comparing this session infomnation with 
information on the system log, the now active 
IMS subsystem is able to perform session re- 
covery to provide end-user transparency. Nor- 
mally, this requires no special recovery action. 
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In the event a reply being sent by the failed 
"active" was never received, the reply will be 
resent after takeover; or, the new "active" may 
request that an unlogged request be resent In 
either case, these session recovery actions are 
performed automatically after takeover, tiius pro- 
viding end-user transparency. 

2. Enable scheduling of normal transaction work. 

3. Initiate data base backouts and forward recov- 
eries. 

These can run in parallel with new work 
because all locks held by the failing "active" 
were reacquired by the "alternate" during 
takeover That is, the specific portions of the 
data l>ases requiring recovery work are pro- 
tected from new work. 

4. Take a simple checkpoint when all recovery 
and takeover-related work has completed. 

The IMS/XRF Implementation 

In order to clarify the invention's methods and 
concepts that were described in the previous sec- 
tion, a sample IMS/XRF configuration will be used 
to explain how IMS/XRF implemented these meth- 
ods. 

In this section. Data Language/1 (DL/1) artd Fast 
Path refer to two altemative data manipulation lan- 
guages that a user can choose from to create and 
modify IMS data bases. For further information, see 
IBM publication GH20-1260, "IMSA/S General In- 
formation Manual". 

Also in this section, a "dependent region" re- 
fers to an OS/VS virtual storage region that con- 
tains an application program. The application pro- 
gram can take several forms: a Batch Message 
Processing (BMP) program, an IMS Fast Path (IFP) 
program, or a Message Processing Program 
(MPP). For further information, see IBM publication 
GH20-1260. 

Several IMS control blocks are mentioned in 
this section. The Program Specification Block 
(PSB) is a user-created control block that describes 
a specific application program~the logical data 
structures and logical terminals it requires. A Parti- 
tion Specification Table (PST) is a control block 
tiiat contains dependent-region information. A PSB 
Directory (PDIR) contains a pointer to ttie PSB 
which contains every Program Communication 
Block required by the application program. There is 
a DMB Directory (DDIR) for each data base that is 
acces^ble by the application program. Each DDIR 
contains a pointer to the control bk>ck (DMB) that 
descrit)es one of the accessible data bases. For 
further infonmation, see IBM publications SH2(>- 
9029. "IMSA/S Utilities Reference Manual", and 
SH20-9026. "IMSA/S Application Programming". 

When referring to the IMS system log, this 



section uses the following terminology: OLDS 
(onLine Data Set) is used interchangeably with 
"IMS system log", and WADS (Write Ahead Data 
Set) refers to a data set tiiat contains log records * 

5 which reflect completed operations but which have 
not yet been written to tiie "OLDS". For further 
information, see IBM publication SH20-9029, 
"IMS/VS Utilities Reference Manual". 

Rnalty, this section refers to several data man- 

70 agement access methods used by IMS: Indexed 
Sequential Access Method (ISAM), Overflow Se- 
quential Access Method (OSAM), and Virtual Stor- 
age Access Method (VSAM). For further informa- 
tion, see IBM publication SH20-9025. "IMSA/S Data 

75 Base Administration Guide". 

The implementation can be more fully appre- 
ciated by following the example through the phases 
described in Rgure 3. Rgure 5 will be used for 
these examples. The sections that follow assume 

20 that the active system is already initialized and 
processing transactions. The alternate subsystem 
will be followed through all of its phases. 

The discussion that follows makes the following 
assumptions atx)ut Rgure 5: 

25 1. VTAM and the 3725 NOP support XRF active 
and backup terminal sessions. 

2. The terminal is supported by NCP and VTAM. 

3. A DU\ program with access to both DL/I and 
Fast Path data bases has been loaded Into a 

30 message-driven dependent region in the active 
subsystem. 

4. The active subsystem is currently processing 
end-user transactions from the terminal. 

35 Initialization Phase 



This phase includes all the functions necessary 
to establish tiie alternate subsystem. Key functions 
here are: 

40 1. bring up IMS/VS as an alternate subsystem. 

2. load IMS load modules, and 

3. initialize IMS control blocks and pools. 

Synchronization and Tracking Phases 

45 

In order to synchronize itself with the "active", 
the altemate subsystem requires that a SNAPO 
Checkpoint be taken by the "active". This action 
consists of logging the "active's" current status. 
50 The series of logs that reflect current status are 
collectively known as the SNAPQ Checkpoint. If the 
"active" has not yet generated this checkpoint, the 
"altemate" has two ways of forcing it to generate 
one at this time: 
55 1. The "altemate" can send a message to the 
Master Tenminal Operator asking the operator to 
enter a command to the active IMS subsystem, 
forcing it to issue a SNAPQ Checkpoint. The 
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"aftemate waits until the checkpoint arrives on 
the "active's" system log. 
2. Optionally, the "alternate" can establish an 
IMS-managed ISC (VTAM LU6) link between the 
active and alternate subsystems. Once estab- s 
lished. the "alternate" can use the link to re- 
quest a SNAPQ Checkpoint. Rgure 6 contains 
the code that establishes the ISC link. 
Statements 4-8 determine if the system has the 
capability of establishing an ISC link. If not, the io 
code to establish the link is bypassed. Thus, this 
direct link between the active and alternate sub- 
systems is optional. All that is really required is the 
active subsystem's log. 

The use of the SNAPQ Checkpoint log records 75 
to get the alternate subsystem in "sync" with the 
active system leads directly into the "tracking 
phase" In which the alternate subsystem continues 
to maintain the "active's" status and recovery in- 
fomnation by continuously reading the additional 20 
log records generated by the active. This enables 
the "alternate" to always be ready to take over 
shoukj the active subsystem fail. 

Rgures 7-9 contain the code that controls the 
processing of the SNAPQ Checkpoint and all sue- 25 
ceeding log records from the active subsystem's 
log. IMS bg records are identified by a four-digit 
numt)er preceded by "X" (for hex). For example, 
X'400r is the Checkpoint log record. The first two 
digits are the type and the last two digits (when 30 
applicable) are the subtype. Lx>oking at Rgure 7, 
statement 2 is the beginning of the loop that con- 
tinuously reads the "active's" log until takeover 
processing stops the "active" from any further log 
activity Statement 17 calls a subroutine to read the 35 
next log record. The code in Rgure 8 determines 
what type of log record it is and which module 
should process it All SNAPQ Checkpoint records 
are type '40' records. Type '40' records cause 
statement 18 to be executed which causes a 40 
branch to location "LOG0040". TTtis location can 
be found in Rgure 9, statement 3. This figure 
contains the code which determines what type of 
information is contained in the different SNAPQ 
Checkpoint records. For example, a '4001' record 45 
causes statement 24 to be executed, which causes 
a branch to location "1064001" to do "start of 
checkpoint" processing. After each bg record is 
processed, control is given back to statement 2 in 
Rgure 7 so that the next log record can be read. 50 

The log records that support both the initial 
SNAPQ Checkpoint and the continued status track- 
ing for IMS/XRF are described below based upon 
the function they support. 



Prepare for Terminal/Sessk>n Takeover 
1. Session initiation/termination tracking: 



The following log records are used to track the 
DC start/stop status. A /START DC command on 
the "active" opens the VTAM ACB enabling logons 
to VTAM. 

- X'4001' Checkpoint log record: used to obtain 
the DC start/stop status at the time of the 
checkpoint. 

- X'02' (IMS Commands) log record: used to 
track /START DC and /STOP DC commands 
so that they can be reprocessed by the al- 
ternate subsystem. 

The following log records are used to track the 
session active/inactive status: 

- X'4005' (CTB Checkpoint): used to capture 
the session status of each node/terminal in 
the system. 

- y^S3' (Session Initiation/Termination): used to 
track the session activation/deactivation of 
nodes/terminals. 

If the log record indicates tiie "active" has estab- 
lished an XRF-capable VTAM session, an attempt 
will be made to establish a "backup" VTAM ses- 
sion by the alternate subsystem (see Figure 5). At 
takeover, these "backup" sessions will be switched 
to "active" sessions and any necessary session 
recovery actions will be performed to provide end- 
user transparency. 

2. MFS terminal format blocks preload/release: 

An IMS Message Format Service (MFS) termi- 
nal format block represents a predefined message 
format tiiat is, moved into the MFS buffer pool as 
needed. Message Format Services are described 
in IBM publication SH20-9053. "IMSA/S Message 
Format Service User's Guide". 

Based upon the Queue Manager Enqueue log 
records (X'35') and Communication Get Unique log 
records QC3V) produced by the active subsystem 
because of terminal activity, the altemate sub- 
system preloads and releases the MFS format 
blocks. A similar action occurs for Fast Path Input 
log records (X*5901') and Fast Patii Output log 
records pC5903'). 

In this manner, the MFS pool contents of the 
alternate subsystem approximates that of the 
"active". In the event of a failure of the "active", 
the "alternate" can take over without delays re- 
quired for MFS format block loading. 

Prepare for new or rescheduled transaction pro- 
cessing 



1. Track-user program scheduling activity: 

Upon receipt of a PST Status log record 
QC4T) (from the initial SNAPQ Checkpoint) or of an 
Application Program Schedule log record (X'08') 
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created by the active sut)system, the alternate sut>- 
system preloads the required DU\ scheduling 
blocks. When an application program completes 
and the "active" produces a Program Termination 
log record pCOT'), the "alternate" releases the cor- 
responding preloaded DU\ scheduling blocks. 

In this manner, the DM program scheduling 
events occurring In the "active" are mirrored by 
the alternate subsystem. In the event of a failure of 
the "active", the "alternate" can take over without 
the delays caused by loading the required DM 
scheduling blocks. 

2. Dependent region preopen: 

To eliminate the delays associated with IMS 
dependent region initialization, dependent regions 
can be started on the IMS/XRF alternate sub- 
system during the Tracking Phase. As with IMSA^S 
Version 1 Release 3. the IMS dependent region 
"preload" function will be performed. This includes 
identifying to Virtual Fetch if necessary. After IMS 
Identify and Sign^n processing which assigns a 
"PST", the dependent region will wait In the IMS 
scheduler for takeover 'MPP' regions will wait on 
Scheduler Subqueue three and BMPs (including 
IFPs) will tie chained off a wait chain from their 
master 'PDIR'. 

These arrangements allow complete operator 
control to start, display, and stop using the existing 
IMS '/DISPLAY A', '/START REGION' and '/STOP 
REGION' commands. They also provide a means 
of properly sequencing the start of the IMS depern 
dent regions and transaction processing at 
takeover. 

3. Dependent region preinitializatk)n routines: 

To allow users to perform application program 
initialization In the IMS dependent regions asso- 
ciated with the alternate subsystem before 
takeover, the ability to exit to user-preinitialization 
routines has been added. These routines may in- 
voke any MVS service or perform other user pro- 
cessing with the exception of IMS calls. 

Prepare for takeover of the active's data bases 

1. Data base status tracking: 

To preserve the single-system image, the al- 
ternate subsystem must track the exact state of all 
of the data bases and areas. The major log records 
used to pass data base status from the active to 
the aitemate subsystem are: 

- X*4006': gives DM data base status at time 
of SNAPQ Checkpoint, 

- X'4084'/X'4087': gives Fast Path Area status 



at time of SNAPQ Checkpoint. 

- X'20'/X'21': gives DM data base open and 
close status changes, 

- X'5921'/X'5922': gives Fast Path Area open 
5 and close status changes, 

- X'4C04'/X'4C08W4C20'/X'4C40'/X'4C82'/X'- 
4CC0': gives DM data base status changes, 
and 

- X'5950': gives Fast Path Area status changes. 
10 Upon receipt of these logs, the alternate sub- 
system updates its data base control blocks. 

Depending on which status items have 
changed, the "alternate" may perfonm additional 
preparatory tasks. The remaining items in this list 
75 describe some of these tasks. 

2. Data base/area preallocation and preopen: 

To reduce or eliminate the time-consuming 

20 process of dynamically allocating and opening the 
IMS data base/area data sets after a takeover, the 
"aitemate" will attempt to allocate them during tiie 
Tracking Phase. 

If the preallocation of the data base/area is 

25 successful, the "alternate" wilt also attempt to 
preopen the data base data or area data sets. A 
preallocation or preopen failure during the Tracking 
Phase is not considered an error. Rather, another 
attempt is made when the data base/area is need- 

30 ed after takeover. 

The initial SNAPQ Checkpoint's DDIR Status 
PC4006') log records cause the aitemate sub- 
system to preatlocate and preopen all data bases 
and area data sets that were allocated and open in 

35 the "active" at the time of the SNAPQ Checkpoint 
Since the active subsystem creates an X'20' or 
X'5921' log record whenever it opens a data base 
or area data set and creates an X'21' or X'5922' 
log record whenever it closes a data base or area 

40 data set. the alternate subsystem can and does 
use these log records to cause it to open or close 
the corresponding data base or area data set. 

3. Data base/area authorization and share level 
45 tracking: 

In order to reduce the process of obtaining IMS 
data base and area authorization and share level 
from DBRC during or after a takeover, the aitemate 

50 subsystem tracks the "active's" authorization activ- 
ity. When the following log records are received, 
the "aitemate* transfers the authorization status 
from the tog record to the appropriate data 
base/area control block: 

55 - X'4006' and X'4084' SNAPQ Checkpoint 
records, and 

- X'4C08' and X'5950' records. 
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4. Data base/area first-update tracking: 



Prepare for parallel data base backout/forward re- 
covery 



The restart processing of IMS systems prior to 
IMS/XRF did very little parallel processing. As a 
result, new-user transactions were not allowed to 
begin until all DL/I backouts were complete and all 
Fast Path Forward Recovery processing was com- 
plete. In order for IMS/XRF to meet its objective of 
reducing outage time, modifications had to be 
made to allow new transactions to be processed as 
soon as possible and in parallel with Restart Re- 
covery processing. These changes will be dis- 
cussed as part of the Takeover Phase. What fol- 
lows are several "tracking" requirements that sup- 
port starting new work in parallel with Dlil backouts 
and Fast Path Forward Recovery. 

1. Dependent region status tracking: 

Even before IMS/XRF, an emergency restarted 
IMS system had to track activities of the failed 
system in order to back out uncommitted DL/I 
changes. This is necessary because DL/I, when 
processing a transaction, updates the data base as 
it goes along. After alt updates are complete, it 
then "commits". Thus, if the system fails before 
the "commit point" is reached, the "uncommitted" 
data base updates must be backed out. But the 
need for an XRF alternate subsystem to perform 
DUI backouts concurrent with the processing of 
new transactions significantly complicated the 
tracking problem. In the XRF environment, the PST 
number no longer uniquely identifies the "Unit of 
Work" (refers to all DL/I change activity for a de- 
pendent region between two consecutive sync 
points). To eliminate this ambiguity, a recovery 
token is used. 



There is a unique recovery token for each 
"Unit of Work", and all log records created for a 
particular "Unit of Work" contain both the PST 
number and the recovery token. 

An earlier section entitled "Track-user program 
scheduling activity" identified the tog records that 
cause DM scheduling blocks to be created and 
released. Those same log records also drive the 
alternate subsystem to create/release a new block 
called a Restart PST block (RPST). There is a 
separate RPST for each unique recovery token. 
Each RPST contains recovery information for a 
specific "Unit of Work". TTie old Restart PST Table 
from pre-XRF IMS releases has been modified to 
act as an anchor for RPSTs. Now called a Restart 
Table, it provides an arrchor point for each unique 
PST number (obtained from the log record). As 
RPSTs are created, they are chained to other 
RPSTs with the same PST number, with the first 
RPST in each chain anchored in the Restart Table 
(see Rgure 10). 

2. DL/I lock tracking: 

25 The alternate subsystem tracks the status of 
the locks for "uncommitted" DM data base 
changes in the active subsystem. This information 
is used during the Takeover Phase to reacquire 
these locks so that lOthe restart backouts can run 

30 concurrent with new transaction processing. The 
locks protect the "uncommitted" data base 
changes from the new transaction processing. 

ft was necessary to expand the amount of 
information included on the existing Data Base 

35 Change tog records and to add a new log record to 
support this function. The following information is 
used: 

a. X'07' - Application Program Termination log 
records 

40 b. X'27' - Data Set Extend log records 

- lock type 

- DCB numl)er 

- DBD name 

- data set extension flags 

45 c. XZT - DM Commit log records 

d. X*41' - Application Checkpoint log records 

e. X*50\ yCbV, and X'52' - DM DB Change log 
records 

- region number and recovery token 
50 - first segment Indicator 

- root/current segment indicator 

- block/control interval RBA (relative byte 
address) 

- offset within block/control interval 
55 - root/segment lock ID 

f. X'Sa* - DM VSAM Control Interval Split Lock 
Obtained log record 

- region number and recovery token 



To eliminate unnecessary DBRC calls at the 
first update of IMS data bases after takeover, the 
altemate subsystem tracks the update activity oc- 5 
curring in the "active". When the following log 
records are received, the "altemate" transfers the 
first-update indicator status from the log record to 
the appropriate data base/area control block. 

The DDIR Status (X'4006') SNAPQ Checkpoint io 
log record is used by the "alternate" to set its data 
base first-update indicators the same as those of 
the "active" at the time of the checkpoint. There- 
after, the following log records are used to track 
changes to these indicators: t5 

- X*50', X*5V, and X*52* log records describe a 
first-update indicator was turned on, and 

- X'4C04* tog record describes a first-update 
indicator that was turned off. 
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- lock obtained indicator 

- lock value 

The lock information obtained from these log 
records is maintained in pools of lock-tracking 
blocks in the "attemate" subsystem using a lock- 
tracking storage management routine. The pools 
dynamically expand and contract as dictated by 
system activity. The information is chained off a 
hash table which is chained off the system backout 
PST used to track the associated dependent region 
activity occurring in the "active" subsystem (see 
Rgure 11). 

After using the region number and recovery 
token to locate the associated VST, the following 
processing occurs: 

a. X'Or. X-ar and X'4r tog records 

When these log records are encountered, all 
'entries* chained off of the associated 'PSP are 
returned to the lock-tracking storage manage- 
ment routine as free space. Should a takeover 
occur, these tocks woukJ not have to be reac- 
quired. 

b. X'27* log records 

Like the X'SO/SI/SZ' log records, the infor- 
mation in the Data Set Extend log records is 
used to create entries In the hash table reflect- 
ing "extend" locks held by the active sub- 
system. 

c. X'SO'. X-Sr and X'52', log records 

The infonmation in the DL/I Data Base 
Change log records is used to create one or 
more 'entries' chained off the hash table asso- 
ciated with the modifying 'PST provided they 
are not duplicates. Duplicates are thrown away. 
The 'entries* created reflect DL/I tocks that were 
acquired by the active subsystem. 

d. X'53' log record 

This log record reflects space management 
activity and. depending on what the activity is, 
can cause an entry to be added to or deleted 
from the hash table. 

3. DL/I "Indoubt" buffer tracking/ireduction: 

To support DL/I I/O Toleration (described in the 
section "Takeover Phase"), it is necessary for the 
altemate subsystem to track the ISAM/OSAI^ block 
and VSAM control intervals to which the active 
subsystem could potentially write. 

To accomplish this, the foltowing information 
on the DM Data Base Change log records written 
by the active subsystem is needed: 

a. X'07' - Appltoation Program Termination log 
records 

b. X3T ' DU\ Commit tog records 

c. X'4V - Application Checkpoint tog records 

d. X'4C01' and X'4C82' - Backout Complete and 
Backout Failure tog records 



e. X'50' and X'51 ' - DM Data Base Change log 
records 

- region number and recovery token 

- first block indicator 
5 - new block Indicator 

- FSE (free space element) count 

- block/control interval RBA (relative block 
address) 

- DL/I subpool-ID 

10 - subpool buffer number 

f. X'53' - DL/I HD (Hierarchical Direct) Bit Map 
Update log record 

- region number and recovery token 

- block/control interval RBA 
75 - DL/1 subpool-ID 

- subpool buffer number. 

The DL/I buffer information obtained from these 
log records is maintained in a pool in the altemate 
subsystem. The pool consists of a group of 

20 chained subpool tables (see Rgure 12). There is 
one table for each ISAf\/l/OSAM and VSAM subpool 
used by the "active". Each table is used to track 
buffers containing "uncommitted" data changes for 
the associated tSAM/OSAM or VSAM subpool. 

25 When "commit" log records are received from the 
"active", the "uncommitted" flag in the associated 
table entries is reset. If needed, each table can be 
expanded up to 255 times to track all of the buffers 
contained in the associated subpool. 

30 Each 'entry' corresponding to a buffer in a DL/I 
subpool (see Rgure 13) contains: 

a. buffer contents 

- data base 

- data set 

35 - relative block number 

b. modifying region bit map. 

The Buffer Tracking tog record processing is: 

a. X'50' and X'Sr log records 

Each DL/I Data Base Change log record is 
40 processed by using the subpool-ID and buffer 
number to locate the corresponding 'entry*. If 
the buffer contents match exactly, the modifying 
PST bit map bit corresponding to the updating 
region is tumed on. 
45 If the buffer contents do not match, the 

contents of the existing 'entry' are overlayed 
with the new information and all modifying PST 
bit map bits are turned off except the one cor- 
responding to the updating region. A complete 
50 search of all 'entries' in all tables for this sub»- 
pool is also performed to check for duplicate 
buffer contents. If a duplicate Is found, that 
entire 'entry' is zeroed. 

b. X'Or. X'37'. X'38'. X'41, and X'4C' log 
55 records 

Whenever an X'Or. X'Sr, or X'41' log 
record is encountered, all the entries in all sub- 
pool tables are processed. In each 'entry', the 
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modifying PST bit map corresponding to the 
region "committing" is tumed off. If this bit map 
becomes zero, the entire 'entry' is zeroed in- 
dicating that the block/control interval would not 
have to be tolerated If a takeover were to occur. 
When an X'4C0r or X'4Ca2' log record is en- 
countered, the above bit map logic is performed 
only on the entry whose data base name match- 
es that found in the log record, 
c. X^SS' log record 

A Bit Map Update log record is processed 
by zeroing the entire 'entry' located using the 
subpool-ID and buffer number. 

4. Fast Path -jndoubt* buffer reduction: 

Unlike DLTI. Fast Path does not write to the 
data base until all changes have been logged 
("committed"). It is possible for the system to fail 
after logging the changes but before the data base 
is updated. Fast Path "indoubt" buffers represent 
logged changes that may not have been written to 
the data base before the active subsystem failed. 
Forward Recovery is the task of writing these 
"indoubt" changes to the data base In case the 
"active" was unable to do so heiore failing. 

In order for IMS/XRF to reduce the time of a 
takeover in a Fast Path environment it was crucial 
to reduce the numt)er of "indoubt" Fast Path Area 
control Intervals during their emergency restart for- 
ward recovery processing. This was accomplished 
by modifying the active subsystem's sync point- 
asynchronous buffer write process to maintain a 
'write pending' bit in the DMHR (a control block 
associated with the buffer). 

Whenever a Fast Path Area Change log record 
OCS^') or Fast Path Commit log record ()C593r) 
Is generated, this bit from 24 "sequential" DMHRs 
Is combined to form a 3-byte bit map. and the 3- 
byte buffer numt>er for the first DMHR checked Is 
placed in a reserved area in these log reconjs. A 
field controlling the first DMHR to t>e checked Is 
then updated so that the next log record will check 
the next 24 "sequential" DMHRs. Hiis results in all 
Fast Path buffers being swept in a cyclic fashion 
periodically so that completed I/O can be detected. 
Figure 14 illustrates this technique. 

Whenever the alternate subsystem processes 
these log records, it uses the first buffer number to 
locate the conresponding DMHR and then pro- 
cesses the pending I/O bit map. For every bit that 
is off, it clears a Forward Recovery required flag in 
the corresponding DMHR. During the processing of 
the Area Change bg record, this flag is tumed on 
In the DMHR associated with the control interval 
being changed. When Forward Recovery runs dur- 
ing takeover, only DMHRs with this bit on need be 
processed. This scheme significantly reduces the 



number of control intervals which must be read and 
thus reduces the time of takeover. 

Tirrter Tracking 

5 

To keep from destroying the integrity of the 
data bases after a switchover, the "clock" on the 
"alternate" must not be earlier than that of the 
"active". Since ultimately these are derived from 

70 the date and time entered by the operator, the 
"alternate" may have to adjust its time. For perfor- 
mance, the IMS time routine DFSFTIMO only is- 
sues an MVS time supervisor service the very first 
time it is invoked. This value is used to calculate 

75 adjustments stored in the IMS System Contents 
Description block (SCD) which allow the conversion 
of the hardware STCK (store clock) instruction val- 
ue to the current date and time. 

Since the time was only set approximately by 

20 the operator, the alternate subsystem monitors the 
"timestamps" on the following "critical" log records 
produced by the "active": 

a. X'4001' - Begin Checkpoint 

b. X*50' and X'51' - Data Base Change 
25 c. X'595x' - Fast Path Area Change. 

For each of the "critical" tog records, the al- 
ternate subsystem compares the timestamp they 
contained generated by the "active" with the cur- 
rent time generated by DFSFTIMO. If timer tracking 
30 discovers that the active subsystem's timestamp is 
greater, it recalculates the adjustments stored in 
the SCD so that the time generated by DFSFTIMO 
will be greater. Rgure 15 illustrates the timer track- 
ing method. 

35 

Surveillance of the Active Subsystem 

All surveillance mechanisms are under direct 
user control. The user selects which mechanisms 

40 to activate and specifies what the time-out values 
for each will be. 

The desired surveillance parameters are speci- 
fied in the IMS PROCLIB member DFSHSBnn. 
Assume that the following surveillance-related pa- 

45 rameters have been specified: 

RDS = (1 .3),L0G = (1 .3).LNK = (3.9),AUTO = YES. 
SWITCH = (TPEND),(RDS,LOG),(IRLM).... 
where 

LNK refers to the ISC link between "active" and 
50 "alternate". 

LOG refers to the active subsystem's system log, 
RDS refers to the active subsystem's Restart Data 
Set, 

IRLM refers to the IMS Resource Lock Manager. 
55 and 

TREND refers to a VTAM failure notification from 
VTAM to IMS. 

These parameters would cause the following 
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surveillance activity: 
LNK = (3,9) 

Requests that the "active" send a signal over 
the ISC link every 3 seconds. The "alternate" 
should invoke the takeover decision function if no 
signal received for more than 9 seconds. 

LOG = (1.3) 

Requests that the alternate subsystem check 
the "active's" system log every second. The 
"alternate" should invoke the takeover decision 
function if more than 3 seconds go by without a 
new log record being generated. 

RDS = (2,4) 

Requests that the "active" place a timestamp 
in the RDS every 2 seconds. The "alternate" 
should invoke the takeover decision function if a 
new timestamp Is not received within 4 seconds. 

SWITCH = (TPEND),(RDS.LOG).(IRLM) 

The "SWITCH" parameter Is used to identify 
which combinations of failures are to trigger a 
takeover (or takeover request). In this example, the 
following failures will cause a takeover to be con- 
sidered: 

1. (TREND): A VTAM failure that results in a 
TPEND exit will trigger takeover decision logic. 

2. (RDS,LOG): Failure of botti RDS and LOG 
surveillance will cause a takeover decision logic 
to be invoked. Failure of one or the other is 
insufficient to trigger a takeover. 

3. (IRLM): An IRLM failure may trigger takeover 
decision logk:. 

AUTO = YES 



Takeover Phase 



This phase includes those functions necessary 
for the altemate subsystem to become the active 
IMS/VS subsystem. Only those actions critical to 
the integrity of IMSA/S are performed. All other 



actions are performed later in parallel with normal 
transactions. Rgures 16 and 17 contain actual code 
from the module DFSRLPOO. The code shown cov- 
ers many of the functions performed during the 
5 Takeover Phase. 

The following functions are performed during 
the Takeover Phase: 

Prohibit further logging by the active subsystem 



The Availability Manager is a component of 
MVS/XA which acts to prevent the failing IMS sub- 
system from accessing the data bases and the 
system log. The method used is described by 
75 Borden et al. "Method Using Token and Token 
Table to Prevent I/O Operations to Selected Data 
Sets After Subsystem Failure". IBM Technical Dis- 
closure Bulletin, Vol. 28. No. 3. August 1985. page 
1108. 

20 The code in Rgure 16 controls the execution of 
the following three functions. 

Finish processing the "active's" system log 



25 All records on the active subsystem's log must 
be read and processed before backouts and for- 
ward recoveries can be set up. The log is then 
closed. 

30 Notify DBRC of the takeover 



Data Base Recovery Control (DBRC)assigns 
the new system log (OLDS). 

35 Switch to the new OLDS log 



Merge local message queue with normal message 
queue 



40 During the Tracking Phase, the alternate sut>- 
system supports operator communications using a 
"local" message queue. At takeover, the 
"altemate" automatically moves any messages on 
this "tocal" message queue to the "real" normal 
message queue. This preserves operator transpar- 
ency and eliminates losing any critical action mes- 
sages. 

The code in Rgure 17 controls the execution of 
the following two functions. 

Initiate the communications network switch 



VTAM is instructed by the alternate IMS sut>- 
system to change its User Application Name Vari- 
55 able to the alternate subsystem's VTAM application 
ID and to perform a session switch whereby the 
"backup" terminal sessions now become the 
"active" sessions. 



Requests that when a takeover condition oc- 
curs, a takeover should proceed without operator 
intervention. A value of "NO" causes the operator 45 
to be alerted of the takeover condition, but the 
takeover will not occur without operator response. 

Tracking will continue until a failure is detected 
which requires the alternate subsystem to take over 
processing, or until the operator enters a command 50 
directing the altemate to take over proces^'ng. 
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Reacquire DM locks 



Locks for "uncommitted" data base changes 
from the active subsystem must be reacquired by 
the "alternate" to protect these changes before 
new transaction processing can be enabled. 

How DL/I locks are tracked by the "alternate" 
was discussed earlier as part of the "Tracking 
Phase" description. Now. at takeover time, the Re- 
start PST Table (RPST) used to track dependent 
region activity is searched for dependent regions 
that were active at the time of the takeover. Each 
RPST contains a PST pointer and it is used to 
locate all DM locks that are chained off the PST. 
These locks are reacquired by the alternate sub- 
system. 

Invoke the I/O Toleration function 



This function allows the takeover to complete 
even though the alternate subsystem cannot guar- 
antee that I/O Prevention has completed on the 
active subsystem. I/O Toleration intercepts at- 
tempts to write to those portions of a data base 
that could potentially be overwritten by the failing 
"active" and saves the changed block or control 
interval in buffers.When I/O Prevention completes, 
the 1/0 Toleration function then does the physical 
writes to the data bases from the buffers that it has 
maintained. 

Enable DM dependent region processing 



Dependent regions that were prestarted in the 
altemate subsystem are now enabled and can be- 
gin entering new transactions concunrent with data 
base backout The reacquired locks preserve data 
base integrity. 

Dependent regions with access to Fast Path 
DEDBs remain suspended.TTiey will be enabled 
after all Fast Path locks are reacquired. 

Active Phase 



This phase includes the functions necessary to 
provide service to the end user. It also includes 
those recovery functions that were set up during 
the Takeover Phase but which can be run in par- 
allel with new work. At this point, takeover has 
completed and the "alternate" system Is now the 
"active" system. 

The functions described bek)w execute in par- 
allel with normal DM transaction proces^ng. How- 
ever, the processing of new transactions involving 
Fast Path data bases has not yet begun. 

Complete the communications network switching 



The terminal session switching activity begun 
during the Takeover Phase continues in parallel 
with new work and other recovery activities until 
completed. As the session switch is performed, 

5 session status information, maintained by NOP, is 
returned to the altemate IMS subsystem. IMS com- 
pares this information with the infonmation recorded 
on the system log by the failing "active". This 
comparison permits the detection of any missing 

10 communication activity and recovery by either re- 
sending the missing output reply or by requesting 
the resending of the missing input request. It is this 
"session recovery" function that provides end ter- 
minal user transparency to the takeover. 

15 

Perform DM dynamic data base backouts 



Restart PSTs (RPSTs) depicted in Rgure 10 
are now used to drive the "backout" effort. As 
20 backouts complete, the affected portions of the 
data base are made available to new transactions. 

Reacquire Fast Path locks 



25 Locks for "committed" data base changes from 

the active subsystem must be reacquired by the 
"altemate" to protect these changes before new 
transaction processing can be enabled. 

All Fast Path buffer headers (DMHRs) are 

30 searched to determine which ones represent 
"indoubt" data base changes. For those that do, 
the appropriate Fast Path locks are reacquired. 

Enable Fast Path dependent region processing 

35 

Fast Path dependent regions that were prestar- 
ted in the altemate subsystem are now enabled 
and can begin entering new transactions concur- 
rent with forward recovery. The reacquired locks 
40 prohitMt new transactions from accessing the 
locked portions of the data base until forward re- 
covery completes and the locks are released. 

Perform Fast Path Forward Recovery 

45 

Prior to IMS/XRF. the Fast Path Fon^rard Re- 
covery was a totally serial process that had to 
complete before new work was started. That has 
been changed, however, to allow the processing of 

50 new work concurrent with Fast Path Forward Re- 
covery during an "XRF" takeover. Now, multiple 
IMS ITASKs are created to perform multiple For- 
ward Recoveries simultaneously and to do them 
concunrent with new work. 

55 Each ITASK obtains a Fast Path data base area 
to process from a chain of areas requiring Forward 
Recovery. Each ITASK then performs all required 
Forward Recoveries for Its area. When finished with 
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an area, the (TASK will go to the chain to remove 
another area This continues until the Forward Re- 
covery chain is empty. 

Claims 

1. A method for ensuring switchover in a restar- 
table data base system between a backup and 
a degrading active processor, the switchover 
being transparent to a terminal accessing the 
active processor with atomic transactions, said 
system utilizing staged storage for data base 
referencing involved in the transactions and for 
logging, said active processor rendering log 
entries over a predetenmined class of activities 
which allow the backup processor to track any 
active processor status changes, comprising 
the steps of: 

a) establishing a session between the termi- 
nal and the active processor: 

b) preparing for active processor un- 
availability by 

- synchronizing with the active proces- 
sor by requesting the active processor 
to take a checkpoint and transfer its 
current status to the log, and obtaining 
this ch^kpoint data from the active 
processor's log by the backup proces- 
sor, 

- tracking and reflecting any active pro- 
cessor status changes by the backup 
processor by concunrentiy accessing 
the log data being produced by the 
active processor, 

- monitoring the active processor by the 
backup processor for detecting active 
processor unavailability; and 

c) in the event of active processor un- 
availability, performing recovery processing 
by the backup processor including taking 
over transaction processing as the new ac- 
tive processor. 

2. A method as claimed in daim 1 wherein 

step b) further comprises monitoring those 
log entries made with reference to the table of 
selected resource locks, and 

step c) further comprises including the 
reacquiring of the locks of the former active 
processor according to the table; and 

d) processing new transactions in the ab- 
sence of contention from the continuing recov- 
ery operations with respect to tiie locked re- 
sources, whereby new transactions are over- 
lapped. 

3. A method as claimed in daim 1, wherein 

step b) further Includes the step of tran- 



siting information from the terminal, through 
the active processor, logging on tiie staged 
storage, whereby new transactions are over- 
lapped. 

5 

4w A method as claimed in claim 3, wherein: 

the step of establishing a session further 
includes the steps of creating and maintaining 
selected resource locks by way of a table; 
70 the step of preparing for active processor 

unavailability synchronizing with, tracking, and 
monitoring the active processor's log entries 
indudes the step of monitoring those tog en- 
tries made with reference to the table of se- 
75 lected resource locks; and 

the step of performing recovery process- 
ing by the backup processor indudes the 
steps of: 

reacquiring the locks of the former active 
20 processor according to the table; and 

processing new transactions in the ab- 
sence of contention from the continuing recov- 
ery operations with respect to the locked re- 
sources. 

25 

5. A method as claimed in claim 3, wherein active 
processor unavailability Is manifest on the 
monitored log entries in the form of failure 
indication of access dereferencing. 

30 

6. A method a claimed in claim 3. wherein the 
step of preparing for active processor un- 
availability includes (I) dynamically rendering 
log entries of the active processor's status, and 

35 (2) synchronizing the backup processor with 

the log entries of the active processor's status. 

Revendicatlons 

40 1. M§thode pour assurer la commutation, dans un 
systfeme de base de donn^es red^marrable, 
entre un processeur de remplacement et un 
processeur actif h fonctionnement d^gradS, la 
commutation ^tant transparente h un terminal 

45 qui accede au processeur actif avec des tran- 
sactions ^l^mentaires, ledit syst^me utilisant 
une m^moire ^tag§e pour la consultation de la 
base de donn^es intervenant dans les transac- 
tions et pour la consignation dans un journal 

50 de marche. ledit processeur actif errant des 
entries de joumal, dans une classe pr4d6ter- 
min^e d'activrt^s,qui permettent au processeur 
de remplacement de suivre tous les change- 
ments d'etat du processeur actif. comprenant 

55 les Stapes de : 

(a) ^tablissement d'une session entre le ter- 
minal et le processeur actif ; 

(b) preparation k I'indisponibilite du proces- 
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4. 



seur actif. par 

- synchronisation avec le processeur 
actif par dentande au processeur actif 
de prendre un point de controle et de 
transferer son ^tat existant au journal. 5 
et obtention. par le processeur de 
remplacement, de ces donn^es de 
point de controle h partir du journal 

du processeur actif. 

- suivi et reproduction, par le proces- io 
seur de remplacement, de tous les 
changements d'etat du processeur ac- 
tif. par acc&s simuttan^ aux donn^es 

de journal produites par le processeur 
actif. 75 

- surveillance du processeur actif par le 
processeur de remplacement. pour 
detector une indisponibilitd du proces- 
seur actif ; et 

(c) dans le cas de rindisponibilitS du pro- 20 
cesseur actif. execution d*un traitement de 
reprise par le processeur de remplacement, 
comprenant la prise en charge du traite- 
ment des transactions comme nouveau pro- 
cesseur actif. 25 

Methode suivant la revendication 1, dans la- 
quetle : 

r^tape (b) comprend en outre la surveillan- 
ce de ces entries de journal ^tablies avec 30 
r^f^rence h la table de venrous de ressources 
choisies. et 

r^tape (c) comprend en outre I'lnclusion 
de la r^acquisition des venrous du processeur 
actif pr^c^ent. conform4ment h la table, et 35 

(d) le traitement des nouvelles transac- 
tions, en rat>sence de conflit resultant des 
operations de reprise qui se poursuivent. en ce 
qui conceme les ressources verrouill^es. de 
sorte que les nouvelles transactions sent en 40 
chevauchement. 

Mdthode ^fvant la revendication 1, dans la- 
quelle : 

r^tape (b) comprend en outre reparation 45 
de transfert des informations venant du termi- 
nal, par I'intermSdiaire du processeur actif. 
avec consignation sur la m^moire iiag&e, de 
sorte que les nouvelles transactions sent en 
chevauchement. so 

Methode suivant la revendication 3, dans la- 
quelle : 

r^tape d'^tablissement d*une session 
comprend en outre les operations de creation 55 
et de maintien de venrous de ressources choi- 
sies. au moyen d*une table ; 

retape de preparation ^ I'indisponibilrte du 



processeur actif. de synchronisation avec 
cetui-cl, de suivi et de surveillance des entries 
de journal du processeur actif, comprend 
I'operation de surveillance des entries de jour- 
nal qui sent etablies avec reference k la table 
de verrous de ressources choisies ; et 

retape d'execution d'un traitement de re- 
prise par le processeur de remplacement com- 
prend les operations de : 

- reacquisition des verrous du premier pro- 
cesseur actif. conformement h la table ; 
et 

- traitement des nouvelles transactions, en 
{'absence de conflit resultant des opera- 
tions de reprise en continuation, en ce 
qui concerrra les ressources verrouiliees. 

& Methode suivant la revendication 3. dans la- 
quelle rindisponibilite du processeur actif se 
manifesto sur les entrees de journal contrd- 
lees. sous la forme d'une indication de defaut 
de dereferendation d'acc^s. 

6. Methode suivant la revendication 3. dans la- 
quelle retape de preparation h rindisponibilite 
du processeur actif comprend (1) la creation 
dynamique d'entrees de journal de retat du 
processeur actif, et (2) la synchronisation du 
processeur de remplacement avec les entrees 
de journal de retat du processeur actif. 

PatentansprUche 

1. Verfahren zum Sichem des Umschaltens in 
einem Datenbanksystem. das wieder in Aniauf 
gebracht werden kann. zwischen einem 
Auswek:h- und einem eine Degradation erfah- 
renden aktiven Prozessor. wobei das Umschal- 
ten fOr eine Datenstation transparent ist, die 
auf den aktiven Prozessor mrt atomaren Trans- 
aktionen zugreift, das System fOr eine in die 
Transaktionen einbezogene Datenbankbezug- 
nahme und fUr das Protokollieren eine gestufte 
Speicherung verwendet und der aktive Prozes- 
sor Protokolleintragungen Obex eine vorbe- 
stimmte Klasse von Aktivitaten durchfUhrt. die 
es ermdglichen. da£ der Ausweichprozessor 
jede Statusanderung des aktiven Prozessors 
aufspOrt. welches die folgenden Schritte uro- 
fa0t 

a) Festlegen einer Sitzung zwischen der Da- 
tenstation und dem aktiven Prozessor, 

b) Vorbereiten auf eine Nicht-VerfUgbarkeit 
des aktiven Prozessors durch: 
Synchronisieren mit dem aktiven Prozessor 
durch Auffordem des aktiven Prozessors, 
einen PrQfpunkt zu nehmen und seinen ak- 
tuellen Status an das Protokoll zu ubertra- 
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gen und Erhatten dieser Prufpunktdaten aus 
dem Protokoll des akliven Prozessors mit- 
tets des Ausweichprozessors. 
Aufspuren und Wiedergeben jeder Status- 
anderung des aktiven Prozessors mittels 5 
des Ausweichprozessors durch gleichlaufen- 
des Zugreifen auf die Protokolldaten. die 
von dem aktiven Prozessor erzeugt werden. 
Uberwachen des aktiven Prozessors mittels 
des Ausweichprozessors urn eine Nicht-Ver- lo 
fOgbarkeit des aktiven Prozessors zu erfas- 
sen und 

c) im Falle einer Nicht-VerfUgbarkeit des 
aktiven Prozessors DurchfUhren einer Wie- 
derherstellungsverarbeitung einschlieBlich 75 
einer Obemahme einer Transaktionsverar- 
beitung mittels des Ausweichprozessors als 
neuen aktiven Prozessor. 

2. Verfahren nach Anspruch 1. bei welchem: 20 
der Schritt b) femer das Uberwachen jener 
Protokotleintragungen umfafit, die unter Bezug- 
nahme auf die TatDelle ausgewahlter Ressour- 
censperren durchgefOhrt wurden und 
der Schritt c) femer folgendes umfaBt Einbe- 25 
Ziehen der Wiederertangung der Sperren des 
frOheren aktiven Prozessors entsprechend der 
Tabelle und 

d) Verart}eiten neuer Transaktionen beim Feh- 
len eines Konkurrenzbetrlebs aus den forttau- 30 
fenden Wiederherstellungsvorgangen hinsicht- 
lich der gesperrten Ressourcen, wodurch neue 
Transaktionen Qberlappt sind. 

3w Verfahren nach Anspruch 1 . bei welchem 35 
der Schritt b) femer den Schritt des Durchlau- 
fens von tnformationen aus der Datenstation 
Gber den aktiven Prozessor unter Protokollie- 
ren auf der gestuften Speicherung umfaBt, wo- 
durch neue Transaktionen Qbertappt sind. 40 

4. Verfahren nach Anspruch 3. be\ welchem 
der Schritt des Festlegens einer Sitzung femer 
die Schrltte des Erzeugens und Aufrechterhal- 
tens ausgewahlter Ressourcenspenren mittels 45 
einer Tabelle umfafit 

der Schritt des Vort)ereltens auf eine Nicht- 
Verfugbarkeit des aktiven Prozessors unter 
Synchronisieren, AufspOren und Oberwachen 
der Protokolleintragungen des aktiven Prozes- so 
sors den Schritt des Qberwachens jener Proto- 
kolleintragungen umfaBt, die unter Bezugnah- 
me auf die Tat)elle ausgewahlter Ressourcen- 
spenren durchgefOhrt wurden und 
der Schritt des DurchfUhrens einer Wiederher- 55 
stellungsverarbeitung mittels des Ausweichpro- 
zessors die folgenden Schritte umfaBt: 
Wiedererlangen der Sperren des frOheren akti- 



ven Prozessors entsprechend der Tabelle und 
Verart»eiten neuer Transaktionen beim Fehlen 
eines Konkurrenzbetriebs aus den fortlaufen- 
den Wiederherstellungsvorgangen hinsichtlich 
der gesperrten Ressourcen. 

& Verfahren nach Anspruch 3. bei welchem eine 
Nicht-VerfOgbarkeit des aktiven Prozessors auf 
den Ot)envachten Protokolleintragungen in 
Form einer Ausfallanzeige einer Referenzfrei- 
hert fur eine Zugriff angezeigt wird. 

6. Verfahren nach Anspruch 3. bei welchem der 
Schritt des Vorbereitens auf eine Nicht-Verfug- 
barkeit des aktiven Prozessors folgendes um- 
fa0t (1) dynamisches DurchfUhren von Proto- 
kolleintragungen des Status des aktiven Pro- 
zessors und (2) Synchronisieren des Aus- 
weichprozessors mit den Protokolleintragungen 
des Status des aktiven Prozessors. 
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FIG. 1 




IMS LOG 



LU6 LINK 
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IMS/XRF INTERSUBSYSTEM COMMUNICATION 

FIG. 2 
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IMS/XRF ACTIVE SYSTEM 



IMS/XRF ALTERNATE SYSTEM 



START IMS 



ACTIVE PHASE 

- START TRANSACTION 
PROCESSING. 



START IMS (ALTERNATE) 



- TAKE SNAPQ CHECKPOINT 



- LOG SYSTEM ACTIVITY 



FAILURE DETECTED OR 

PLANNED TAKEOVER REQUESTED 



TERMINATION 



initialization phase 

synchronization phase 

— 1. request snapq checkpoint 
*-2. use the checkpoint to: 

a: build control blocks to 
same level as "active". 
B. preopen data bases. 
c. prestart terminal backup 
sessions. 

3. ALLOW dependent REGION 

prestart. 

4. start surveillance to detect 
"active" failure. 

tracking phase 

use the "active's" system log 
records to continue: 

a. update control blocks. 

b. preopen/close data bases. 

c. prestart/terminate 
terminal backup sessions. 

0. collect backout and 
forward recovery data for 
data bases. 

takeover phase 

1. setup/start parallel data base 
backout and forward recovery. 

2. initiate terminal session 
takeover. 

3. enable dependent region to 
start entering transactions. 

active phase 



SWITCH 

TERMINAL 

SESSIONS 



DATA BASE 
FORWARD/ 
BACKOUT 
RECOVERY 



PROCESS 
NEW TRXS 



NORMAL PROCESSING 



IMS/XRF PHASES 

FIG. 3 
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ACTIVE AND BACKUP TERMINAL SESSIONS 

FIG. 4 
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"ACTIVE" SESSION 



ISC LU6 LINK 



DATA BASE 





"BACKUP" SESSION 



TERMINAL 



SAMPLE IMS/XRF ACTIVE-ALTERNATE CONFIGURATION 
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**♦***★♦***♦+*♦*******♦♦♦**♦♦♦•♦*****♦*******♦*♦♦★♦♦♦*★*********♦ 

ESTABLISH XRF SYSTEM LINK IF IT IS AN ALTERNATE §YSTEM ' * 



1 SPACE 1 

2 TM FRBFLAGI.FRBBCKUP ALTERNATE SYSTEM? 

3 BNO RSTOOOlO ELSE, 

4 L R3.FRBLICLB ISC SYSTEM LINK CLB ADDRESS 

5 LTR R3,R3 ISC SYSTEM LINK EXISTS? 

6 BZ RSTOOOlO ELSE, 

7 TM SCDCFLG1,SCDC1ACB VTAM ACB OPENED? 

8 BNO RSTOOOlO ELSE, 

9 USING IECTDECB,R3 SET CLB ADDRESSABILITY 

10 01 CLBVaGl.CLBVlSIM SET SIMLOGON REQUEST 

11 MI CLBFLAG2,X'FF*-CLB2NOIN-CLB2N0OU 

12 NI CLBFLAG2,X'FF'-CLB2N0QU-CLB2IDLE 

13 L RIS.CLBCTB POINT RELATING CTB 

14 DROP R3 RESET CLB ADDRESSABILITY 

15 USING CTB,R15 SET CTB ADDRESSABILITY 

16 NI CTBFLAG2,X'FF'-CTB2IN0P RESET INOPE FLAG 

17 DROP R15 RESET CTB ADDRESSABILITY 

18 ICM R4.B'llir,=CL4' OPN' SET POST CODE 

19 IPOST ECB={R3),PC0DE«{R4) POST ISC LINK CLB 



20 RSTOOOlO OS OH 

FIG. 6 ESTABLISHING THE OPTIONAL ISC LINK 
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READ THE LOG . * 

SPACE 1 
LOGREAD OS OH 

LTR R15,R15 RC FROM PROC LAST RECORD 

BNZ ABMD168 ISSUE ABEND 

*.. START SURVEILLANCE HERE IF ALL THE DC PREOPEN FINISHED. 
*.. THE SURVEILLANCE HAS HOT STARTED YET. 



LOGREAD 



L 


R14,SCDFRB 


LOAD FRB POINTER 


LTR 


R14,R14 


XRF ENVIRONMENT? 


BNM 


LOGREAD 1 


ELSE, DON'T BOTHER. 


USING 


FRB,R14 


SET FRB BASE 


TM 


FRBSRVF1,FRBSRVIN 


SURVEILLANCE FUNC INITIATED? 


BO 


LOGREADl 


THEN, DON'T BOTHER. 


TM 


FRBP0PNN,X'08' 


DC PREOPEN HAS COMPLETED? 


BNO 


LOGREADl 


ELSE. DON'T BOTHER. 


DROP 


R14 


RESET FRB BASE 


L 


R15,=A(SURVSTAT) 


SURVEILLANCE STATUS ROUTINE 


BALR 


R14,R15 


START SURVEILLANCE 


DS 


OH 




L 


R15,TAPEGET 


A(GET ROUTINE) 


BALR 


R14,R15 


GET RECORD 


LTR 


R15,R15 


OKAY? 


BZ 


LOGTYPE 


YES - DETERMINE TYPE 


CH 


R15,=H'4' 


END OF FILE ON LOG? 


BNE 


ABN03141 


NO - ERROR 


B 


L06E0F 


YES 



FIG. 7 



READING THE ACTIVE'S SYSTEM LOG 
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*** DETERMINE THE RECORD TYPE * 



**************************************************************** 



1 




SPACE 


1 








2 




USING 


LOG01,R2 








3 


LOGTYPE 


DS 


OH 








4 




LR 


R2,R1 




LOG RECORD REG 


5 




SR 


Rl.Rl 




ZERO 




6 




IC 


Rl.CHKLCODE 


GET LOG RECORD TYPE 


7 




L 


R14.L0GRECXA 


GET A(LOGRECXT) 


8 




IC 


R1.0{R1.R14) 


GET BRANCH TABLE INDEX 


9 




B 


LOGBR(Rl) 


GOTO PROPER ROUTINE 


10 


LOGBR 


DS 


OH 




TYPE 


WHERE TO 


11 




B 


LOGREAO 


0 


6F, 71-FF 


- GET NEXT RECORD 


12 




B 


L0G0056 


4 


56 


- DFSRESPO 


13 




B 


L0G005A 


8 


5A-6C 


- DFSCRSPO 


14 




B 


L0G0059 


C 


59 


- DBFERSTO 


15 




3 


L0G0050 


10 


50-53, 41 


- DFSRBLBO 


16 




B 


L0G004C 


14 


4C 


- DFSRDBPO 


17 




B 


L0G0047 


18 


47 


- DFSRDBPO 


18 




B 


L0G0040' 


IC 


40 


- DFSRLPOO + OTHERS 


19 




B 


LQG0037 


20 . 


37 


- DFSCRSPO, DFSRBLBO, 


20 




3 


L0G0007 


24 


07-08 


- DFSRDBPO 


21 




B 


L0G0006 


28 


06 


- DFSRBLBO 


22 




B 


L0G005A1 2C 


REST 


- DFSCRSPO 


23 




B 


L060038 


30 


38 


- DFSCRSPO + DFSRBLBO 


24 




B 


L0G0070 


34 


70 


- DFSICV90 


25 




B 


L0G006D 


38 


6D 


- DFSRLPOO 


26 




B 


L0G0025 


3C 


25 


- DBFTOLRO OR DFSTOLRO 


27 




B 


L0G0026 


40 


26 


- DBFTOLRO OR DFSTOLRO 


28 




B 


L0G0020 


44 


20-21 


- DFSRDBPO, DFSHRDBO 


29 




B 


L060027 


48 


27 


- OFSRELPO 



PROCESSING THE ACTIVE'S LOG RECORDS 



FIG. 8 
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*** CHECKPOINT LOG RECORDS - '40' * 



1 SPACE 1 

2 USING LOG01,R2 

3 L0GG040 DS OH 

4 L R14,SCDFRB A{FRB) 

5 USING FRB,R14 SET ADDRESSABILITY 

6 LTR R14,R14 AN XRF SYSTEM? 

7 BNM L0G00402 NO, SKIP XRF CODE 

8 TM FRBFLAGl.FRBACTV+FRBRSTRT THE ALTERNATE SYS? 

9 BNO L0G00402 NO, MUST NRE/ERE 

10 TM RSTCTL2.RST2X80 BLDQ COMPLETED? 

11 BO LOGREAD YES, GET NEXT RECORD 

12 SPACE 1 

13 DROP R14 

14 SPACE 1 

15 L0G00402 DS OH 

16 LR R0,R1 DEBUG 

17 SR Rl.Rl ZERO 

18 IC Rl.CHKTYPE GET CHKPT RECORD TYPE 

19 L R14,CHKRECXA A(CHKRECXT) 

20 IC R1,0(R1,R14) GET BRANCH TABLE INDEX 

21 B L0640BR(R1) GOTO PROPER ROUTINE 

22 L0G40BR DS OH 

23 B LOGREAD 0 READ NEXT RECORD 

24 B L0G4001 4 4001 START CHECKPOINT 

25 B L0G4002 8 4002 MESSAGE QUEUE 

26 B L0G4003 C 4003-4005, 4008-4014 S 4020 

27 B L0G4006 10 4006-4007 & 4015 

28 B L0G4030 14 4030 DFSRESPO 

29 8 L0G4O70 18 4070-4079 MSDB LOG RECORDS 

30 B L0G4080 IC 4080 FAST PATH 

31 B L0G4098 20 4098 END CHECKPOINT 

32 B L0G4099 24 4099 END MESSAGE QUEUE 

33 B L0G4025 28 4025 EEQE 

34 B L0G4026 2C 4026 lOT BUFFER 



PROCESSING THE ACTIVE'S SNAPQ CHECKPOINT 

FIG. 9 
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DEPENDENT REGION RESTART TABLE STRUCTURE 



FIG. 10 
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PSTLTRK 



HASH TABLE 



ENTRY 



J 



PST 
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HASH TABLE 



ENTRY 
I 1 



DL/I LOCK TRACKING: POOL STRUCTURE 
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SCO 
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SU6P00L 
TABLE 



SUBPOOL 
OVERFLOW 
JPSIE 



SUBPOOL 
OVERFLOW 
TABLE 



SUBPOOL 
TABLE 



SUBPOOL 
TABLE 



j 



SUBPOOL 
OVERFLOW 
TABLE 
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DL/r BUFFER TRACKING POOL STRUCTURE 



FIG. 12 
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DATA SET 


RELATIVE BLOCK NUMBER 


255 BITS 




■ - BUFFER CONTENTS 


MODIFYING PST BIT MAP 



OL/I BUFFER TRACKING TABLE ENTRY 

FIG. 13 
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ESCD (FAST PATH) 



ESCDDMHR 
ESCDMFBN 



ESCOCAOR 



FIRST DMHR 



NUMBER DMHR'S 
FIRST / NEXT 
TO CHECK 



24 
DMHR'S 



FAST PATH 
DMHR'S 



FAST PATH 
BUFFER POOL 



FAST PATH LOG RECORD 
X'5937' OR X'5950' 



FIRST 
BUFFER 



PENDING I/O 
BIT MAP 



FAST PATH "INDOUBT" BUFFER REDUCTION 

FIG. 14 



ACTIVE SUBSYSTEM'S PROCESSING I 

I 



BACKUP SUBSYSTEM'S PROCESSING 



SCO 

SCDCKVAL 



DFSFTIMO 



TIME SUPERVISOR SERVICE 
CALLED ONCE AT STARTUP 



I 

"CRITICAL" 
LOG RECORD- 
TIMESTAMP 



COMPARE 



DFSFTIMO 



SCO 

SCDCKVAL 
A A 



IF 'ACTIVE* TIME 



GREATER RECALCULATE 



TIME SUPERVISOR SERVICE 
CALLED ONCE AT STARTUP 



TIMER TRACKING: OVERVIEW 
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************ TAKEOVER CODE EXTRACTED FROM DFSRLPOO ************ 

it 

*** CLOSE INPUT LOG 

L R15.TAPCL0SE A(CLOSE INPUT LOG) 
BALR R14,R15 

Itititifititititiiirit'kifirit'ltit'kititifititit Jtitititititifitit'ititli ititii Itititititit lil^iticitiritiitit'kitit'ir'itltifirit 

*** PERFORM MESSAGE QUEUE CLEANUP 

TM SCDRSCTL,SCDRSERE ERE? 

BNO L0GE0F15 NO - BRANCH 

BAL RS.QRSTCLN CALL QRST FOR CLEANUP 



IDENTIO OS OH 
*** DBRC SIGN-ON 

it 'ft it 'if it itit 'it itif it it it it it it it 1i it it it ii irit it ititn^ititit irititititititit^ It itiiititltititit'ttitltltitlt Itltitit iiit 

MVC 0PTTADDR(8).SCDDATE SAVE CHECKPOINT 

L R15,0BRCSIGN A(DBRC SIGNON RTN) 

BALR R14,R15 SIGNON 

CH R15,=H'4' WAS SIGNON SUCCESSFUL 

BH ABN0042 NO - ABEND 

*** OPEN (OR SWITCH TO) A NEW SYSTEM LOG 

L0GE0F23 OS OH 

L RIS.OPNCLS A(OPEN LOG) 

BALR R14,R15 AND OPEN THE OUTPUT LOG 

**• MERGE MESSAGES FROM "LOCAL" TO "NORMAL" QUEUE 

LA R1.8 REQ CODE FOR MSG Q MERGE 

L R15,=V(DFSHCI00) POINT DFSHCIOO ~ 
BALR R14,RI5 CALL FOR MSG Q-MERGE 



XRF TAKEOVER HIGHLIGHTS (PART 1) 



FIG. 16 
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************ 



TAKEOVER CODE EXTRACTED FROM DFSRLPOO 



'k'kifieitifirk'k'kirk 



*** SCHEDULE SESSION TAKEOVER IN CASE OF SYSTEM TAKEOVER 



L RIS.SCOFRB 
LTR R15,R15 
BNM L0GE0F25 
USING FRB.RIS 



TM 

BNO 

L 

E0F24LP1 OS 
LA 
SLL 
OR 
CS 
BNE 
LA 
SLL 
I CM 
NR 
CS 
BNE 
L 



FRBFLAGl.FRBBCKUP 
L0GE0F25 



LOAD FRB POINTER 
XRF ALTERNATE SYSTEM? 
ELSE SKIP 

SET FRB ADDRESSABILITY 
ALTERNATE SYS (TAKEOVER)? 
ELSE, SKIP 
RO.FRBCFLGS GET COMMUNICATION FLAGS 
OH 

SESSION TAKEOVER REQUEST 
TURN THE FRBCITKO BIT ON 
IN FRBCFL6S FIELD 
SET SESSION TAKEOVER REQUEST 
NOOP, LOOP BACK 



Rl, FRBCITKO 
Rl,3*8 
Rl.RO 

R0,R1,FRBCFLGS 
E0F24LPI 
RO.255-FRBC1P0P 
R0,3*8 
R0,3'01ir,=XL3'FFFFFF' 



FRBCIPOP BIT OFF CONDITION 



R0,R1 

RO.Rl.FRBCFLGS IF PREOPEN INIT COMPLETE? 

L0GE0F25 ELSE, BYPASS IPOST OF HCIIO 

Rl.FRBCPSTA GET DC PREOPEN PST ADDR 

IPOST ECB={R1),P0ST=?C0DE2 REQUEST SESSION TAKEOVER 
**★★*♦*■***■*■**-*»**»****★♦**** ****>»» *******-*★**★★♦★★**-»*★★»*★**★ 



*** 
*** 



LOCK REAQUIRE 
CREATE OL/I lOT EEOE 



CALL DFSHRALO AND 
CALL OFSHREQO 



L0GE0F37 DS 
L 

LTR 
BNM 
USING 
L 

BALR 

L 

L 

BALR 
DROP 
BCPT 



OH 

R 14, SCO FRB 

RI4,R14 

LOGE0F38 

FRB, R 14 

R15,FRBHRAL0 

R14,R15 

R14,SCDFRB 

RIS.FRBHREQO 

R14,R15 

R14 

RS 



R14 — > A(FAST RESTART BLK) 
XRF GENNED? 

NO - BYPASS DFSHRALO CALL. 
SET DSECT ADDRESSABILITY. 
R15 -> A(DFSHRALO). 
CALL LOCK REAQUIRE MODULE 
RE LOAD FRB PTR 
LOCATE ROUTINE 

AND CALL 
RESET DSECT ADDRESSABILITY. 
RECORD VALID RESTART 



A*****************************************'********************* 



XRF TAKEOVER HIGHLIGHTS (PART 2) 



FIG. 17 



